Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(macOS): Tauri V2 Update Permission Denied Error #2067

Open
wants to merge 6 commits into
base: v2
Choose a base branch
from

Conversation

jLynx
Copy link
Contributor

@jLynx jLynx commented Nov 18, 2024

Description

Improves the macOS app update process by adding proper handling for permission-denied scenarios and implementing a more robust extraction mechanism.
This is the Tauri V2 version of my previous PR tauri-apps/tauri#10427

image

Changes

  • Creates separate temporary directories for backup and extraction to better manage the update process
  • Adds proper directory creation for extracted files to prevent path-related issues
  • Implements fallback to AppleScript with admin privileges when standard file operations fail due to permissions
  • Improves error handling and cleanup in case of failures during the update process
  • Maintains atomic update operations to prevent partial updates

Why

The current implementation could fail on macOS when the app lacks sufficient permissions to modify its own directory, which is common in certain installation locations. This update provides a more reliable solution by:

  1. Properly handling permission-denied scenarios
  2. Using admin privileges when necessary
  3. Ensuring clean rollback in case of failures
  4. Addressed the problem of Tauri updater failing for standard (non-admin) users on macOS with a "Permission Denied" error as stated in this issue [bug] [macOs] Tauri updater fails with "Tauri API error: Permission Denied (os error 13)" for standard (non-admin) users tauri#8104.

Testing

  • Tested app updates on an admin account and a use account
  • Verified successful updates both with and without admin privileges

@jLynx jLynx requested a review from a team as a code owner November 18, 2024 00:54
@jLynx
Copy link
Contributor Author

jLynx commented Nov 27, 2024

@tweidinger In response to your previous comment on the V1 version of this. I understand the concerns about TOCTU attacks, but I believe the current implementation has several security mitigations that make it reasonably safe:

  1. Controlled Temporary Directory:
  • We're using tempfile which creates directories with restricted permissions (700 by default)
  • The temporary directories are created with random names and are only accessible to the current user
  • The lifetime of the temporary files is very short - only during the update process
  1. Limited Attack Window:
  • The window of vulnerability is extremely small - only during the file move operation
  • The privileged operation (via osascript) is only used for the final move, not for extraction or execution
  • We're not executing any content from the temporary directory
  1. Existing Validations:
  • The update package is still verified via signature before extraction
  • The contents are validated in memory before being written to the temp directory
  • The final move operation is atomic

The current approach solves real-world issues with updates on macOS while maintaining a reasonable security posture. The attack surface requires an attacker to already have user-level access and the ability to time their attack precisely during the update process.

CC: @lucasfernog @chippers

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant